Introduction: Side Projects

Side projects aren’t necessary to succeed in this industry, but they offer a huge advantage for your learning and career development. I strongly recommend that, if at all possible, you have one or two side projects you are constantly shipping.

Learn better#

All side projects are forms of applying what you learn. It’s amazing how much you learn when you try to use what you have learned in theory. You quickly find the holes in your understanding. You learn what is true and what is marketing BS. You learn that not everyone knows what they’re talking about, despite sounding smart. Finally, you remember what you use a whole lot better.

Breakable toys#

The book Apprenticeship Patterns popularized this way of viewing side projects. Many software developers work in an environment where the consequences of failure are high. However, experience is built upon failure. Exceptional progress can only be made when exceptional risks are safe to take. By working on smaller projects outside of work, you have a way to experiment and make mistakes without the usual consequences.

You can get past Hello World quicker with a breakable toy. When you encounter a new way to do something, like a new library or framework, you can put it into your side project to see how it feels in a nontrivial use case you know well. When your colleagues ask for your opinion on certain technologies, you’re no longer making a decision based on docs or marketing; you can assert some authority from actually having used it in something “real.”

📝 Examples: Both Kent C. Dodds and Adam Rackis maintain bookshelf apps (Kent’s, Adam’s) as breakable toys-- must be something about avid book readers! If learning a language, Vincent Prouillet notes that creating a static site generator is a great side project because of all the functionality needed.

Prototyping new things#

You don’t just have to work on apps. You can try building your own X from scratch or creating a “lite” version of something you already use. People often learn so much from building a “lite version” of their main app or tool that they end up applying it to their actual work, like Dominic Gannaway did with Inferno.js (now he is on the React core team) or Zack Argyle building a Pinterest PWA and convincing the CEO to switch the real Pinterest site over to a PWA (now he manages the React Native team). Google used to be famous for its 20% rule, which spawned amazing side projects like Gmail, Chromecast, and AdSense (worth billions of dollars).

Practice shipping#

Shipping is a whole other discipline than coding. When you ship code at work, you are doing the shipping equivalent of bumper bowling. The system is set up to prevent you from failing as much as possible. You have coworkers and bosses around you to help you decide what to do, when to do it, how to market it, what your budget is, what not to do, and so on. When you ship, your coworkers are obliged to pay attention.

None of this is true, when you work on side projects. Side projects you practice all the non-code aspects of coding that make your code matter: decision making, prioritizing, marketing, documenting. If you dream of founding a startup someday, you should practice these skills before you start relying on them for a living. If you are a junior engineer looking to grow to senior, understand that one of the few things everybody identifies as a key quality of a senior engineer is the ability to independently execute. Act for the job you want.

Permissionless improvement#

The other thing about side projects is that nobody can tell you no. As long as you don’t give away company secrets, you can usually work on whatever you want. The danger with company laddering, however well-intentioned, is that it puts a cap on your career progression based on a theoretical expectation of an average engineer.

But you are not an average engineer. You’re reading this course in your free time, for crying out loud! If you are feeling undervalued or artificially limited at work, your side projects are an outlet where you can put your full awesome on display. You shouldn’t have to keep your project a secret: If you have a supportive manager, they will not only recognize that you are trying to stretch your wings but actively encourage you and give you resources. A manager that is afraid of you improving yourself shouldn’t be your manager at all. Which leads us nicely to…

Resume builder#

Side projects should never be a required part of any job application, but it usually helps to show that you can work independently and that you are passionate and curious about technology. Your current job might use some legacy technologies for a good reason, but if you want to switch jobs to work on a newer tech stack and have no experience in that stack, it can be a resume saver to have a side project that demonstrates you have built something nontrivial with the stack you want to work with.

Of course, some people take this too far and do resume driven development. In practice, I find that this is more often a criticism by bitter Reddit trolls than actual dev behavior. If you are pursuing a career in Infosec, getting bug bounties on BugCrowd and HackerOne are excellent resume items.

Improve your productivity#

Your side project can be a dev tool that makes you more efficient at work. This can often be the best kind of side project to do because the side projects you learn the most from are the side Projects you use. Plus, this saves you valuable time at work. Think expansively of the entire range of tasks you do-- from things you do fifty times a day to things you only do once a month. Randall Munroe of xkcd has a great chart that does the math on how much time you should invest in automating tasks:

User empathy#

Your side project can often put you in the shoes of your company’s end-user. As an employee, you can usually try it for free. Since you build the product, you might think you understand it intimately-- until you actually try to use it as a user. Suddenly all the bug reports become real, the bad design decisions matter, and documentation and good copy are critical rather than a chore.

Making money#

If your side project makes money, you suddenly gain options. You don’t have to go all Pieter Levels-level Indie Hacker, but a little passive income on the side never hurts. However, if it ends up going unexpectedly well, as happened for devs like Taylor, Mike, and Anne, you now have an uncapped upside. Mikael Cho ended up pivoting his entire business to his side project, Unsplash. When you work, you are renting out your time. When you do a side project, you own equity. Rich people own equity. Be like rich people. Your project also serves as a good BATNA - when negotiating your next role.

📝 Note: A brief note on potentially money-making projects: Be careful of IP assignment. Most developers sign a “proprietary invention agreement”, which may range from “we don’t care what you do in your own time” to “we own you 24/7” and maybe variously unenforceable depending on what jurisdiction you are in. Negative outcomes may range from getting fired (though it worked out for Reilly Chase - always good to have options!) to the company claiming they own your project (!).

Try to make clear what the acceptable boundaries are; this is easier if you don’t keep your project a secret from your manager. Common sense rules apply. Don’t directly compete with or clone your employer’s products. Get explicit permission if you need to work on it during work hours. Don’t use company equipment to make your project (just for the avoidance of doubt down the line).

Productive fun#

Don’t forget you can work on things simply because it is fun. You don’t need a better reason than that. However, there is a difference between passive fun (leaning back, watching Netflix, reading) and productive fun (making, experimenting, failing). Most people are extremely imbalanced in their Consume : Create ratio-- you can correct this with a fun side project!